Если в индексе всплывают служебные URL WordPress — страницы поиска, архивы с параметрами, служебные файлы плагинов, — первым делом обычно смотрят не на мета-теги, а на robots.txt. Это не универсальная «кнопка скрыть», но для части мусорных URL он работает быстро и предсказуемо. Проблема в том, что в WordPress его часто правят по шаблону: закрывают лишнее, забывают про sitemap, а потом удивляются, почему бот не видит важные страницы или почему правила вообще не применяются.
Ниже — рабочий сценарий: что именно закрывать, как собрать robots.txt без конфликтов с WordPress и как проверить, что вы не перекрыли лишнее.
Когда robots.txt действительно нужен
Этот файл полезен, если нужно ограничить обход служебных разделов, а не «удалить страницу из поиска». Для удаления уже проиндексированных URL он подходит плохо: поисковик может оставить адрес в индексе без содержимого. Поэтому сначала стоит понять, что именно вы хотите решить.
Типичные случаи
- в индексе появляются URL поиска вида
?s=; - есть служебные архивы, которые не несут ценности для поиска;
- плагин генерирует технические пути, которые не должны тратиться на обход;
- нужно убрать из сканирования большие области сайта, чтобы бот быстрее доходил до важных страниц.
Если задача — убрать страницу из индекса полностью, чаще нужен noindex или удаление URL через инструменты поисковой системы. robots.txt здесь только вспомогательный слой.
Диагностика проблемы перед правкой
Перед изменением файла проверьте, что именно уже доступно ботам. На практике полезно открыть несколько URL из разных групп:
- главная и важные посадочные страницы;
- страница поиска сайта;
- архивы рубрик и меток;
- URL с параметрами сортировки или фильтрации;
- служебные пути плагинов, если они есть в индексе.
Если у сайта уже есть robots.txt, посмотрите, не создаёт ли его тема, SEO-плагин или серверная конфигурация. В WordPress файл может отдаваться виртуально, даже если физического файла нет в корне. Это важно: править нужно не «где попало», а в том месте, которое реально обслуживает сайт.
Быстрая проверка с консоли:
curl -I https://example.com/robots.txtЕсли ответ 200 OK, файл доступен. Если там редирект, 403 или 404, сначала разберитесь с доступом и источником файла. Иначе вы будете править одно, а поисковик увидит другое.
Что можно закрывать, а что лучше не трогать
Ниже — практичное разделение. Оно не универсально для всех проектов, но как базовая схема работает нормально.
| Что закрывать | Зачем | Риск |
|---|---|---|
/wp-admin/ | служебная зона админки не нужна в индексе | не закрывайте критичные пути, если у вас есть нестандартные интеграции |
/wp-includes/ | технические файлы не должны сканироваться как контент | обычно безопасно |
?s= | поисковые выдачи сайта часто создают мусорные URL | можно случайно ограничить полезный внутренний поиск, если он нужен для пользователей |
| параметры сортировки и фильтров | снижение дублей и лишнего обхода | не закрывайте, если эти URL реально используются как посадочные |
Не стоит бездумно закрывать:
/wp-content/uploads/— там обычно лежат изображения, которые нужны в поиске;- CSS и JS, если тема или плагин зависят от их обхода для рендеринга;
- весь сайт целиком, если вы просто хотите убрать несколько технических разделов.
Пошаговая настройка robots.txt в WordPress
Шаг 1. Определите источник файла
Если у вас стоит SEO-плагин, он может генерировать robots.txt сам. В этом случае не надо одновременно создавать физический файл и надеяться, что правила сложатся как задумано. Выберите один источник: либо виртуальный файл, либо реальный файл в корне сайта.
Шаг 2. Соберите минимальный рабочий вариант
Для обычного сайта WordPress можно начать с аккуратного набора правил:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Disallow: /?s=
Disallow: /*?replytocom=
Sitemap: https://example.com/sitemap_index.xmlЗдесь есть важная деталь: Allow: /wp-admin/admin-ajax.php нужен, если фронтенд или плагины используют AJAX-запросы. Без него некоторые формы и интерактивные элементы могут работать нестабильно.
Шаг 3. Добавьте правила только для реально проблемных URL
Если у вас есть параметры сортировки, можно закрыть только их, а не весь раздел:
User-agent: *
Disallow: /*?orderby=
Disallow: /*?filter_
Disallow: /*?utm_Но тут важно понимать компромисс: если параметр используется как часть полезной страницы, его закрытие может помешать обходу нужного контента. Поэтому сначала проверьте, какие URL реально генерируются и индексируются.
Шаг 4. Не дублируйте sitemap в нескольких местах
В robots.txt достаточно одной строки Sitemap: на актуальную карту сайта. Если SEO-плагин уже добавляет её автоматически, не плодите вторую и третью копию. Это не ломает сайт, но создаёт лишний шум при проверке.
Если нужен физический robots.txt, а не виртуальный
Иногда удобнее держать файл в корне проекта, особенно если вы не хотите зависеть от логики плагина. Тогда создайте robots.txt рядом с wp-config.php и проверьте права на чтение.
Пример содержимого:
User-agent: *
Disallow: /wp-admin/
Allow: /wp-admin/admin-ajax.php
Disallow: /wp-includes/
Sitemap: https://example.com/sitemap_index.xmlПосле этого убедитесь, что сервер не отдаёт другой вариант файла через кэш, CDN или правила редиректа. Если у вас подключён кеш на уровне сервера, иногда старый robots.txt продолжает отдаваться даже после правки.
Как проверить, что решение сработало
Проверка должна быть не «файл открылся», а «бот видит именно те правила, которые вы задали».
- откройте
https://example.com/robots.txtв браузере и убедитесь, что там актуальный текст; - проверьте ответ сервера через
curl -Iилиcurl https://example.com/robots.txt; - посмотрите, не закрыт ли случайно sitemap;
- проверьте в инструменте для вебмастеров, как поисковик читает файл;
- откройте несколько URL, которые вы закрывали, и убедитесь, что они больше не должны обходиться.
Если страница всё ещё в индексе, это не всегда ошибка robots.txt. Возможно, URL уже был найден раньше и теперь требует отдельного удаления или noindex.
Частые ошибки и как их исправить
Закрыли всё подряд
Самая частая ошибка — правило Disallow: / или слишком широкий шаблон. В результате бот перестаёт обходить вообще весь сайт. Исправление простое: оставьте только точечные правила и проверьте, не перекрывают ли они важные разделы.
Ожидали удаления из индекса
robots.txt не гарантирует, что URL исчезнет из выдачи. Если страница уже в индексе, поисковик может оставить её как «без описания» или с устаревшим фрагментом. Для удаления нужен другой механизм: noindex, 404/410 или инструменты удаления в панели вебмастера.
Забыли про кэш
После изменения файла старый вариант может продолжать отдаваться из кеша CDN или сервера. Если проверка показывает старое содержимое, очистите кеш на всех уровнях: плагин кеширования, сервер, CDN.
Смешали виртуальный и физический файл
Если SEO-плагин генерирует виртуальный robots.txt, а вы добавили физический файл, итоговый результат может зависеть от конфигурации сервера. В таких случаях лучше оставить один источник правды.
Безопасность и производительность: что учесть
robots.txt не защищает от доступа к файлам и не скрывает данные. Он только подсказывает поисковым роботам, что обходить не нужно. Поэтому не используйте его как замену правам доступа, noindex или серверным ограничениям.
С точки зрения производительности он полезен, когда вы сокращаете обход мусорных URL. Но не стоит пытаться закрыть им всё подряд ради «экономии краулинга». Если вы закроете важные CSS/JS или полезные архивы, поисковик может хуже понимать страницу, а это уже ударит по индексации.
Если на сайте много дублей, параметров и служебных страниц, имеет смысл не только править robots.txt, но и навести порядок в генерации URL. В таких задачах часто помогает связка SEO-настроек и чистки дублей, например через